1. Bounded Contexts

1. CRM Context
   Owns people and organizations: Contact, Company, relationship links, communication preferences, addresses, consent, and referral entry points.
2. Listings and Demand Context
   Owns supply and demand: Activity (marketed instruction/listing), Requirement (client demand), matching, and pipeline visibility.
3. Transactions Context
   Owns negotiation and agreement state: Offer, deal progression fields, contractual milestones, and party roles around a deal.
4. Tenancy and Property Management Context
   Owns occupancy lifecycle: Tenancy, tenancy parties, lease hierarchy (head/sub), progression and management data.
5. Asset and Geography Context
   Owns real estate structure: Asset base type, Property, Portfolio, Address, floors/areas, and asset-level metadata.
6. Organization and Security Context
   Owns operational structure and access projection: User, Department, Business, roles, security attributes, negotiation ownership.
7. Integration and Async Processing Context
   Owns background jobs and external systems: DocuSign, Dotmailer, SAP, Thirdfort, notifications, feeds, Elasticsearch updates, and sync/error handling.

2. Major Aggregates Per Context

1. CRM
   • Contact aggregate, Company aggregate, Contact-Company association, Contact relationship graph, address associations.
2. Listings and Demand
   • Activity aggregate, Requirement aggregate, Match aggregate linking them, negotiator/department ownership.
3. Transactions
   • Offer aggregate with role-based parties (applicant, broker, lender, surveyor, etc.) and status progression.
4. Tenancy and PM
   • Tenancy aggregate with linked asset/activity/requirement, tenancy parties, reviews/breaks, lease lineage.
5. Asset and Geography
   • Asset aggregate root with Property/Portfolio specializations and shared address model.
6. Organization and Security
   • User aggregate, department/business membership, role bindings, resource-security attributes.
7. Integration and Async
   • WebJob handlers as process/application layer components that mutate domain aggregates and publish side effects.

3. Relationship Backbone (most important)

1. Asset to Activity: one-to-many
2. Asset to Tenancy: one-to-many
3. Requirement to Activity: many-to-many via Match
4. Activity to Offer: one-to-many
5. Requirement to Offer: one-to-many
6. Tenancy to Asset: many-to-one
7. Contact to Company: many-to-many via association entity
8. Contact to Address and Company to Address: association-based (not direct single owner)
9. User to Department/Business: many-to-one from user perspective

4. Typical Business Flow

1. Lead captured against Contact and optionally Company
2. Requirement created (demand)
3. Activity created on an Asset (supply)
4. Match links demand to supply
5. Offer tracks negotiation
6. Accepted/completed progression produces Tenancy
7. WebJobs synchronize, notify, enrich, and index

5. Integration Points (high-value)

1. Document and signing workflows (DocuSign)
2. Marketing/communications sync (Dotmailer, notifications, SMS/email jobs)
3. External data/compliance updates (SAP, Thirdfort, Fixflo and others)
4. Search indexing and feed jobs (Elasticsearch and feed webjobs)

6. Practical Implications for Change Design

1. Changes to party roles should be made in party subtypes, not by adding fixed role columns.
2. Cross-context changes usually pass through Activity, Requirement, Offer, and Tenancy in that order.
3. Async side effects belong in WebJobs/process handlers; core invariants should remain in domain/application logic.
4. Security and visibility are cross-cutting and should be treated as first-class when modifying aggregates.